A structured speci cation of an active database

Active database systems are a current focus of considerable research interest, as a means of supporting a range of tasks including constraint enforcement, real-time applications and derived data management. However, although many diierent proposals have been made for active rule systems, such proposals are normally described in an informal manner, which makes it diicult to understand how diierent proposals diier or how a set of rules will behave. This paper compares a range of formal speciication methods, considering how suitable they are for describing active database func-tionality, and then shows how the model-based notation Object-Z, an object-oriented extension of Z, can be used to specify the semantics of a representative active database system, namely Starburst. 1 Active database systems Active database systems extend a pre-existing database model (relational, extended relational, functional or object-oriented) with some variant of a common paradigm of computation, event-condition-action (ECA) rules. An event represents some occurrence in the database; this may be either an access or modiica-tion to a speciic data item managed by the database or an external occurrence such as the state of a clock. The occurrence of such an event triggers the checking of a condition: this is a boolean-valued query over the database having no side eeects. If this query returns true, an action will be performed: this can be any operation expressible in the database. These systems have a number of advantages over passive database systems. Time-based events provide a straightforward way of expressing security constraints, such as preventing access at certain times, or real-time constructs, like the pre-emption of a query if it has not completed within the time allotted for it. Data events are the focus of the system described here. These provide a way of implementing semantic integrity constraints which modularizes their implementation better than competing approaches. Where these other approaches have to distribute enforcement of the constraint across all code (queries or embedded accesses), an active implementation builds the constraint into the run-time behaviour of the database by compiling a small set of rules. No semantic checking of subsequently run application programs is required to prevent violation of the implemented constraints. This is especially important for an object-oriented system, where access is not generally through a query language ; the overhead of checking all application code in a general-purpose programming language for constraint violations would be very expensive, and the amount of rechecking involved would make evolution …